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(54) Centralized cerif icate management system for two-way interactive communication devices 
in data networks 


(57) The present invention discloses a method tor 
managing centralized certificates in a proxy server de- 
Vic (114) tor a plurality of thin client devices (302. 304, 
306) coupled thereto through a data network (102). A 
user account database, accessible by the proxy server, 
comprises a plurality of user accounts with each o1 the 
thin client devices being associated with one or more of 
the user accounts. Each of the user accounts comprises 
a device ID (316), a list of public and private keys (326) 
assigned to the user account, and a list of certificates 
(320) assigned to the user account. A certificate man- 


agement module reserves a fixed number of free certif- 
icates signed by a Certificate Authority and their respec- 
tive private keys in a certificate database (328) and fre- 
quently updates the free certificate according to a cer- 
tificate updating message. Whenever a user account is 
created for a thin client device, the certificate manage- 
ment module fetches one or more free certificates from 
the certificate database and associates the fetched cer- 
tificate(s) to the created account and at the same time 
creates new free certificates with the Certificate Author- 
ity to fill in the certificate database. 
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D scription 

BACKGROUND OF THE INVENTION 

Field of Invention ^ 

[0001] The present invention relates to data security 
between server computers and client computers in data 
networks, and more particularly relates to systems for 
managingi in a proxy server computer, digital certifi- 
cates for two-way interactive communication devices 
over the data networks; wherein the two-way interactive 
communication devices, such as mobile devices, cellu- 
lar phones, landline telephones and Internet appliance 
controllers, have generally limited computing resources 
such as computing power, rnemory and graphical dis- 
play capability. 

Description of the Related Art 

20 

[0002] A fast-growing trend on the I ntemet is e lectron- 
ic commerce. The electronic commerce is an integrative 
concept designed to drawtogether a wide range of busi- 
ness support services, trading support systems lor com- 
modities, products, customized products and custom- 
built goods and services; ordering and logistic support 
systems; settlement support systems; and manage- 
ment information and statistical reporting systems, all 
via the Internet, It is well known, however, that the Inter- 
net is a wide open, public and international network of 30 
interconnected computers and electronic devices 
around the world. The ability to send and receive secure 
data becomes a fundamental requirement in conducting 
electronic commerce over the Internet. To transact busi- 
ness over the open network, a business or organization 55 
must have an efficient and reliable manner to establish 
its identity and credibility to protect itself and its custom- 
ers from impostors. Similarly, custonriers need assur- 
ance that their private information they may submit over 
the Internet can not be read by anyone but the business 40 
that they submit to. 

[0003] One of the on-going efforts to ensure private 
communications or business transactions between two 
authenticated parties is to use digital certificates to bind 
the identities of the two parties to a pair of electronic 45 
keys that can be used to encrypt and sign digital infor- 
mation transmitted over the Internet. A digital certificate 
makes it possible to verify someone's claim that they 
have the right to use a given key, which helps prevent 
others from using phony keys to impersonate authorized so 
users. Used In conjunction with encryption, digital cer- 
tificates provide a more complete security solution by 
assuring the identity of all parties involved In a transac- 
tion through an open network. 

[0004] The current architecture for using the digital 55 
certificates is binding between two computers, one b - 
ing a client computer and the other being a server com- 
puter, on the Internet, that means both computers phys- 


ically hold their own certificates, requiring a memory 
space to keep certificates. In case, one of the certificates 
becomes invalid (expired, revoked or no longer usable), 
the computer that owns the invalid certificate niay ac- 
quire a new certificate from a certificate issuing author- 
ity. However, the acquiring process generally takes a 
number of minutes and a significant amount of comput- 
ing power. When a communication sessbn between the 
two computers is established, the two computers au- 
thenticate each other by examining the counterpart's 
certificate. A session key is created when the authenti- 
cation is successful and a secure communlcatk)n ses- 
sion thus commences using the session key to encrypt 
all information exchanging between the two computers. 
The authentication process also takes a significant 
amount of computing power. 

[0005] When the client computer is a smalt two-way 
communication devk:e such as a mobile computing de- 
vice, a cellular phone, a landline telephone, or an Inter- 
net appliance controller, the above architecture is hardly 
applicable. To increase the portability and mobility, most 
of such two-way communication devices are designed 
snnall in size, light in weight, low in power consumption 
and as economically as possible. Such designs, often 
considered as thin designs, result in a very limited com- 
puting power, typically equivalent to less than one per- 
cent of what is provided in a typical desktop or portable 
computer and the memory capacity thereof is generally 
less than 250 kilobytes. That rneans that the thin client 
devices would not have extra memory spaces to store 
a number of certificates and the required computing 
power to acquire a new certificate in real time if one of 
the possessed certificates becomes invalid. There is 
thus a great need for providing the thin clients with a 
mechanism to effectively manage the certificates. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0006] These and other features, aspects, and advan- 
tages of the present invention will become better under- 
stood with regard to the following description, appended 
claims, and accompanying drawings where: 

Figure 1 illustrates, as an exemplary illustration, 
how the certificates are being used between a client 
device and a merchant server; 

Figure 2 illustrates a schenr^tk: representation of a 
mobile data network comprising an airnet and a 
landnet, in which the present invention may be prac- . 
tised; 

Figure 3 illustrates a representatbn of the present 
invention inte racting with other parts or components 
in the data network; 

Figures 4A and 4B demonstrate an example in 
which a user of a mobile device requests certlficat s 
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f rom a user-specifi d CA; 

Figure 5 depicts a block diagram ot various compo- 
nents in a certificate management module in the 
present invention; and 

Figures 6A and 6B illustrate an operation flowchart 
showing processes and procedures for managing 
certificates in a server device tor thin clients over a 
. data network. 

DETAILED DESCRIPTION OF THE INVENTION 
Notation and Nomenclature 

[0007] In the following detailed description of the 
present invention, numerous specific details are set 
forth in order to provide a thorough understanding of the 
present invention. However, it will become obvious to 
those skilled in the art that the present invention may be 
practised without these specific details. In other instanc- 
es, well known methods, procedures, components, and 
circuitry have not been described in detail to avoid un- 
necessarily obscuring aspects of the present invention. 
[0008] The detailed description of the present inven- 
tion in the following are presented largely in terms of 
procedures, steps, logic blocks, processing, and other 
symbolic representations that resemble of data 
processing devices coupled to networks. These process 
descriptions and representations are the means used 
by those experienced or skilled in the art to most effec- 
tively convey the substance of their work to others 
skilled in the art. The present invention is a centralized 
certificate management system for two-way interactive 
communication devices in data networks. The method 
along with the architecture to be described in detail be- 
low is a self-consistent sequence ot processes or steps 
leading to a desired result. These steps or processes 
are those requiring physical manipulations of physical 
quantities. Usually, though not necessarily, these quan- 
tities may take the form of electrical signals capable of 
being stored, transferred, combined, compared, dis- 
played and otherwise manipulated in a computer sys- 
t m or electronic computing devices. It proves conven- 
ient at times, principally for reasons of common usage, 
to refer to these signals as bits, values, elements, sym- 
bols, operations, messages, terms, numbers, or the like. 
It should be borne in mind that all of these similar terms 
are to be associated with the appropriate physical quan- 
tities and are merely convenient labels applied to these 
quantities. Unless specifically stated othenwise as ap- 
parent from the loilowing description, it is appreciated 
that throughout the present Invention, discussions uti- 
lizing terms such as "processing" or "computing" or "ver- 
ifying" or "displaying" or the like, refer to the actions and 
processes of a computing device that manipulates and 
transforms data represented as physical quantities with- 
in the computing device's registers and memories into 


other data similarly represented as physical quantities 
within the computing device or other electronic devices. 

Introduction to Digital Certificates 

5 

[0009] A digital certificate or certificate, sometimes re- 
ferred as digital ID or security certificate, is a piece of 
information, often stored as a text file, to be used by the 
secure sockets layer (SSL) protocol to establish a se- 
10 cure connection between two parties over an open data 
network. In the simplest form, a certificate contains a 
public key and a name. As commonly used, a certificate 
also contains an expiration date, the name of the certi-- 
tying authority that issued the certificate, a serial 
IS number, and perhaps other inforrriation. Most important- 
ly, it contains the digital signature of the certificate issu- 
er. I.e. an erlcrypted "fingerprint" that can be used to ver- 
ify the contents of the certificate. 
[0010] A digital certificate, or simply certificate, is is- 
20 sued by a Certification Authority (CA) and signed with 
the CA's private key. The most widely accepted fornnat 
for Digital IDs is diefined by the CCITT X.509 interna- 
tional standard; thus certificates can be read or written 
by any application complying with the CCITT X.509. A 
25 digital certificate uses public key encryption techniques 
that are based on a pair of related keys, a public key 
and a private key. In publk: key encryption, the public 
key is made available to anyone who wants to corre- 
spond with the owner of the key pair. The public key can 
30 be used to verify a message signed with the private key 
or encrypt messages that can only be decrypted using 
the private key. The security of messages encrypted this 
way relies on the security of the private key, whrch must 
be protected against unauthorized use. 
35 [0011] The key pair in a certificate Is bound to a user's 
name and other identifying information. When installed 
in an HTML browser, such as Netscape Navigator from 
Netscape Communication Inc. in California or Internet 
Explorer from Microsoft Corporation in Washington, the 
40 certificate functions as an electronic credential that sites 
being contacted can examine. This sometimes enables 
digital certificates to replace password dialogs lor infor- 
mation or services that require membership or restrict 
access to particular users. For example, when one 
45 sends messages to a merchant web site, he signs the 
messages and encloses his digital ID to assure the re- 
cipient of the message that the message was actually 
sent by him. When the merchant receives digitally 
signed messages, the signer's digital ID Is verified to de- 
50 termine that no forgery or false representation has oc- 
curred. Generally, once a user obtains a certificate, he 
can set up his security-enhanced web or e-mail appli- 
cation to use the certificate automatically. Figure 1 illus- 
trates the authentication process using the digital IDs 
55 between the cli nt and the merchant server. 

[0012] The most secure use of authentication in- 
volves enclosing one or more certificates with every 
signed message. The receiver of the message would 
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verify th certificate using the certifying authority's pub- 
lic key and, now confident of the public key of the sender, 
verify the messag 's signature. There may be two or 
more certificates enclosed with the message, forming a 
hierarchical chain, wherein one certificate testifies to the 
authenticity of the previous certificate. At the end of the 
certificate hierarchy is a top-level certifying authority, 
which is trusted without a certificate from any other cer- 
tifying authority. The public key of the top-level certifying 
authority must be independently known, for example, by 
being widely published. In other words, a sender whose 
company is known to the receiver may need to enclose 
only one certificate (issued by the company), whereas 
a sender whose company is unknown to the receiver 
may need to enclose two or more certificates. For higher 
grade of security, it is a common practice to enclose just 
enough of a certificate chain so that the issuer of the 
highest level certificate in the chain is well known to the 
receiver. If there are multiple recipients, then enough 
certificates should be Included to cover what each re- 
cipient might need. 

The Preferred Embodiment 

[0013] Referring now to the drawings, in which like nu- 
merals refer to like parts throughout the several views. 
Figure 2 illustrates a schematic representation of a data 
network 1 00 in which the present invention may be prac- 
tised. The data network 100. comprises an airnet 102 
that is generally called wireless network and a landnet 
104 that is generally a landline network, each acting as 
a communication medium for data transmission there- 
through. The aimet 102, in which the data transmission 
is via the air, is sometimes referred to as a carrier net- 
work because each airnet is controlled and operated by 
a carrier, for example AT&T and GTE, each having its 
own communication scheme, such as CDPD, CDMA, 
GSM and TDMA for the airnet 102. The landnet 104 or 
the Internet, used interchangeably herein, may be the 
Internet, the Intranet or other private networks. Refer- 
enced by 106 is one of the mobile devices that can be 
a mobile device, a cellular phone, a landline telephone 
or an Internet appliance controller, capable of commu- 
nicating with the airnet 102 via an antenna 108. It is gen- 
erally understood that the airnet 102 communicates si- 
multaneously with a plurality of two-way communication 
devices, of which only a mobile device 106 is shown in 
the figure. Similarly, connected to the Internet 104 are 
a plurality of desktop PCs 110 and a plurality of server 
computers 112, though only one representative respec- 
tively is shown in the figure. The PC 110, as shown in 
the figure, may be a personal computer SPL 300 from 
^ NEC Technologies Inc. and runs a HTML Web browser 
via the Internet 104 using HTTP to access information 
stored in the web server 112 that may be a workstatk^n 
from SUN Microsystems Inc. It is understood to those 
skilled in the art that the PC 110 can store accessible 
information therein so as to become a web server as 


well. Between the Internet 104 and the aimet 102 there 
is a proxy server computer 11 4 performing data commu- 
nication therebetween. The proxy sender computer 114, 
also referred to as link server or gateway server com- 
puter, may be a workstation or a personal computer and 
performs mapping or translation f unctk)ns, for example, 
mapping from one protocol to another, thereby the mo- 
bile device 106 can be in communication with any one 
of the servers 112 or the PCs 110, respectively. 
[0014] The communication protocol in the Internet 
104 is the well known HyperText Transfer Protocol (HT- 
TP) or HTTPS, a secure version of HTTP, and runs on 
TCP and controls the connection of a well known Hy- 
perText Markup Language Web browser, or HTML Web 
browser in the server 114, to the Web' server 112, and 
the exchange of information therebetween. HTTPS sup- 
ports SSL that is used mostly in secure and authenticat- 
ed communications between the HTML browsers and 
web servers- A common notation In the HTML browsers 
is the use of "https" before a universal resource k>cator, 
or URL, which indicates that an SSL connectk>n will be 
established. In an SSL connection one side, preferably 
the server side, of the connection shall have a certificate 
that must be authenticated by the counterpart side. 
Each side then encrypts what it sends out using infor- 
mation from either its own, the other side or both skje 
certificate, ensuring that only the intended recipient can 
decrypt it, and that the other side can be sure the data 
come from the place it claims to have come from, and 
that the message has not been tampered with. 
[001 5] The communication protocol between the mo- 
bile device 106 and the proxy sen/er 114 via the airnet 
102 is Handheld Device Transport Protocol (HDTP), or 
Secure Uplink Gateway Protocol (SUGP), which prefer- 
ably runs on User Datagram Protocol (UDP) and con- 
trols the corinection of a HDML Web browser, In the mo- 
bile device 106, to the proxy server 114; where HDML 
stands tor Handheld Device Markup Language. HDML, 
similar to that of HTML, is a tag based document lan- 
guage and comprises a set of commands or statements 
specified in a card that specifies how information dis- 
played on a small screen of the mobile device 106. Nor- 
mally a number of cards are grouped into a deck that is 
the smallest unit of HDML information that can be ex- 
changed between the mobile device 106 and the proxy 
server 114. The specifications of HDTP and HDML Lan- 
guage Reference Version 2.0 are well known and readily 
available, their content being incorporated herein by ref- 
erence. The HDTP is a session-level protocol that re- 
sembles HTTP but without incurring the overhead there- 
of and is highly optimized for use in thin devices that 
have significantly less computing power and memory. 
Further it is understood to those skilled in the art thai 
the UDP does not require a connection to be established 
between a client and a server before information can be 
exchanged, which eliminates the need of exchanging a 
large number of packets during a session creation be- 
tween a client and a serv r. Exchanging a very small 
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number of packets during a transaction is one ot the de- 
sired features for a nnobile device with very limited com- 
puting power and memory to effectively interact with a 
landline device. 

[0016] The mobile device 106 comprises a display 
screen 11 6 and a keyboard pad 118. The hardware com- 
ponents including a microcontroller, a ROM and a RAM 
in the mobile phone 106 are known to those skilled in 
the art and so the hardware components are not de- 
scribed in detail herein. With the display screen 116 and 
the keypad 116. a. user of the mobile device 106 can 
interactively communicate with the proxy sender 114 
over the airnet 102. According to one embodiment, one 
portion of the compiled and linked processes of the 
present invention are stored in the ROM as a client mod- 
ule that causes the mobile device 106 to operate with 
the proxy server 114. Upon activation of a predeter- 
mined key sequence utilizing the keypad 118, the micro- 
controller initiates a communication session request to 
the proxy server 114 using the client module in the ROM. 
Upon establishing the communication session, the mo- 
bile device 106 typically receives a single HDML deck 
from the proxy server 1 1 4 and stores the deck as cached 
in the RAM. As described above, an HDML deck com- 
prises one or more cards and each card includes the 
information required to generate a screen display on the 
display screen 116. The number of cards in a card deck 
is selected to facilitate efficient use of the resources in 
the mobile device 106 and in the airnet network 102. 
Generally, one of the cards Is a choice card shows a 
sequence of frequently visited web sites and allows the 
user to choose one to make a secure and authenticated 
communication session with through the proxy server 
114, The process of using certificates to establish such 
communication session will be described below. 
[0017] Referring now to Figure 3. there is depicted a 
representation of the present invention interacting with 
other parts or components in the data network. Refer- 
enced by 302. 304 and 306 are three representatives of 
a plurality of the mobile devices coupled to the airnet 
102, similarly referenced by 310, 312 and 314 are three 
representatives ot a plurality of landline devices coupled 
to the landnet 104. The proxy server device which can 
be the one 1 1 4 in Figure 2. couples the airnet 1 02 to the 
landnet 104. therefore any mobile devices can commu- 
nicate with the landline devices via the airnet 102. the 
proxy server 114 and the landnet 104. To facilitate the 
description of the present invention, the internal block 
diagrams of the mobile device 302 and the link server 
114 are respectively illustrated. Other processes and 
hardware are known to those skilled in the art and are 
not illustrated in detail in the figure for clarity. 
[0018] Each of the mobile devices, such as the one 
302, is assigned to a device ID 316. The device ID 316 
can be a phone number of the device or a combination 
of an IP address and a port number, tor example: 
204.163.165.132:01905 where 204,163.165.132 is the 
IP address and 01905 is the port number. The device 


ID 316 is further associated with a subscriber ID 318 
authorized by a carrier in the proxy server 114 as part 
of the procedures to activate the mobile device 302 by 
establishing a us r account 324 in the proxy server 114. 

s The subscriber ID 318 may take the fomn ot, for exam- 
ple. 861234567-10900_pn.mobile.att.net by AT&T 
Wireless Sen^ice. The subscriber ID 318 is a unique 
identification of the mobile device 302. In other words, 
each ot the mobile devices 302. 304 and 306 has its own 

70 unique device ID that corresponds to a subscriber ID 
indexing a respective user account in the proxy server 
114. The following description is based on the mobile 
device 302 and the associated account 324, it will be 
appreciated by those skilled in the art. that the descrip- 

IS tion is equally applied to a plurality of the mobile devices 
in communication simultaneously with the proxy server 
114. 

[0019] Theaccount324, indexed by the devk:e ID 316 
or the subscriber ID 318 and identified by an address 
20 identifier such as a URL, is a data structure comprising 
user info 322. a certificate list 320 and a private key list 
326. wherein the user Info 22 Includes the account con- 
figuration and other account related Information, such 
as username and password. The URL of the account 
25 may take the form of. for example, http://www.att.com/ 
Pocketnet which indicates that the airnet 102 is operat- 
ed by AT&T wireless service. The certificate list 320 con- 
tains or points to a list of designated certificates issued 
by one or more C As and the private key list 326 contains 
30 a list of keys, each corresponding respectively to each 
certificate in the certificate list 320. All certificates in the 
certificate list 320 are exclusively associated with the 
particular account. Generally the proxy server 114 main- 
tains a large number of such user accounts, preferably 
35 kept in a database 328, each of the user accounts is 
respectively associated to each of the mobile devrces 
that are subscribed with the same carrier and serviced 
by the proxy server 114. It can be appreciated that the 
certificates in one account are different from those in 
40 other accounts because of the respective association of 
the certificates with each of the accounts therein. 
[0020] It has been described that It takes a notk:eable 
length of time in a regular full-power desktop computer 
to obtain a certificate from a CA and generate a pair of 
4S keys; private and public keys therefor. To minimize the 
latency of obtaining a certificate with a mobile device, a 
certificate manager module (CMM) 342 maintains a cer- 
tificate database, preferably in the database 328, to re- 
serve a list of undesignated but issued certificates, re- 
so ferred to as free certificates, from one or different CAs. 
Whenever a user account Is created to activate a mobile 
device that requires one or more certificates to access 
certain web servers requiring a certificate, a certificate 
request (certRequest) signal is sent to the CMM 342 to 
55 fetch needed certificates from the certificate database. 
Upon receiving the fetched certificates from the certifi- 
cate database, the CMM 342 assigns the certificates to 
the particular account by attaching the device ID 316 
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and other account rnfornriation, hence the fetched certif- 
icates beconne associated to the particular account and 
are placed in the certificate list 320. Meanwhile the CMM 
examines the number of the free certificates available 
in the certificate database, if the number is below a val- 
ue, for example 200 certificates, referred to as thresh- 
old, the CMM calls the HTTP module 330 to establish a 
connection to the appropriate CA via the landnet 104 to 
obtain new free certificates to fill up the certificate data- 
base till the level of the threshold is reached, as such 
there are always sufficient free certificates available in 
the certificate database to supply any new accounts with 
the ready-to-use free certificates. 
[0021] It can be now appreciated by those skilled in 
the art that the present invention uses the computing 
power in a proxy server to carry out the task of obtaining 
certificates asynchronously, apart from the tradition of 
obtaining certificates in local devices that normally have 
sufficient computing power, and further, unlike the tradi- 
tion of physically storing the certificates in the local de- 
vices, the present invention maintains the certificates in 
a user account in the proxy server. Managing certificates 
in a proxy server for all clients makes it possible for the 
clients to access any secure web sites without demand- 
ing additional computing power and memory. Other ad- 
vantages will be further appreciated in the description 
below. 

[0022] The certificates are issued by a CA that can be 
any trusted central administration willing to vouch for the 
identities of those to whom it issues certificates and their 
association with a given key, for example, a company or 
a university may issue certificates to its own employees 
or its students. To accommodate the need of the mobile 
device 302 to obtain certificates from a CA other than 
the one that the CMM 342 uses to get the free certifi- 
cates from, the server module 340 allows the user there- 
of to log onto the user account 324 associated to the 
mobile device 302 through any computers, for example, 
a PC 314 coupled in the landnet 104, This is accom- 
plished by logging onto the user account 324 using the 
address identifier of the user account 324, for example: 
http://www.att.com/Pocketnet. To ensure that the ac- 
count 324 is accessed by an authorized user, a set of 
credential Information, such as a usemame and pass- 
word, is required. The server module 340 through the 
HTTP module 330 will prompt for the username and 
password when the user connects the PC 314 to the 
URL using http://www.att.com/Pocketnet. Entries of a 
pair of matched username and password will be granted 
the permission to access the account. 
[0023] To provide flexibility and security to the ac- 
count, the username and password are fully adminis- 
trated by the user. The user of the mobile device S02 
can access the device's account 324 in the proxy server 
114 using the mobile device 302 that is equipped with a 
HDML browser. Knowing the URL of the account, the 
us r depresses a predetermined key to cause the client 
module 332 to send a request comprising the URL and 


10 

the device ID 316 to UDP Interface 336 that subsequent- 
ly establishes a communication session to the proxy 
servdr 114 using the HDTP. The requ st is r ceived by 
the corresponding UDP interface 128 in the proxy server 

s 114 and carried out by the server module 340 to see If 
the device ID is authorized. The proxy server 114 then 
acknowledges the request with a response sent to the 
mobile device 302 for username and password. It 
should be noted that the response does not request from 

10 the user a pair of usemame and password to permit an 
access to the account, in fact the permission to access 
to the account has been granted by matching the device 
ID 316 in the request from the mobile device 302 and 
the stored device ID of the account 320 in the proxy serv- 

t5 er 114. Instead, the response allows the user to self- 
provision the account by entering a pair of new user- 
name and password. Once the account 320 receives the 
pair of new username and password, the account, i.e. 
the user info 322, is updated. After the self -provisioning 

20 procedure, the user may use the PC 31 4 which has pref- 
erably a sufficient computing power and equipped with 
a more familiar HTML browser to establish a communi- 
cation session using HTTP and the URL to the account. 
The newly provisioned username and password are en- 

25 tered in the PC 314 vtrtien prompted and sent over in a 
packet format to the proxy server 114 using HTTP In 
which the HTTP server 330 extracts the username and 
password and the server module 340 performs an au- 
thorization check with the user info 322 in the memory. 

30 If the entered username and password are matched, the 
authorization is granted so that the user or the PC 314 
is permitted to access the account 324. The user can 
now request a certificate from a specified CA and up- 
dates the certificate list 320 and the key list 326. The 

35 process of obtaining a certificate from a CA using an 
HTML browser is known to those skilled in the art and 
therefore is not to be described herein. It can be appre- 
ciated that, besides the capabilities provided by the 
CMM. the self-provisioning capability allows a user to 

40 tailor the certificates to his own needs while still relying 
on the proxy server to keep all the certificates designat- 
ed to the mobile device 302. 

[0024] Based on Figure 3, Figures 4A and 4B demon- 
strate an example in which the user of the mobile device 

45 302 requests certificates from user-specified CAs. After 
a predetermined key is pressed, the mobile device 302 
uses HDTP to make a request to connect to the proxy 
server 1 1 4 using the URL of the account designed to the 
mobile device: 302861 23456-1 0900_pn.moblle.xyz. 

50 net. The device ID 86123456-10900 is extracted from 
the request and verified that there is an account 324 in- 
dexed by the same device ID 86123456-10900. Upon 
the verification, the user of the rrK)blle device 302 is 
prompted for a set of username and password. It has 

ss been described that username and password are not 
the required information for the mobile device 302 to ac- 
cess the account 324, rather the user is given a permis- 
sion to administrate the username and password. If the 
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the password = ^'^•="*°° ' -ogsword. The user can 
wrth the new ^^^a,^^^^ 

the account 324- The PO .^^^^^^^ ^^g, 3,. 

browser providing ^ '""9 J?^' account 324 much more 
the user to man.^^^^^^^^^ HTTP connect- 

efficiently. The PC 314 es^o 

usin9theURL.forexample^mob^><yz ^ ^^^^ 3,. 

«,ay 354 in the '1^°?;^^^ Jser is prompted at 

counts in ^^^^'^^^^''^lllt^^^ and password. The 
th PC 314 tor « „^ername and •123456- 

user must ente smrth toMh ^^^^^^ ^p^^ 

forthepasswordtogetthroug ^^^^^^^ 

receiving the " ,he ones in the ac- 

gateway 354 ^^^^'^^'^^^J^^^u^ PC or the user is 
count 324. 324. if the entered 

not permmed to access tiieac 
usernameandpas^wor^-^tch^^^^^^^^^ 
324. the 9«;f-«yf3^fiTnow use the HTML browser 

pointer to . -^"'-'^^^ J^ose in the art that 

4B, it can be aPP^«<='^'^ J° ^° b,e capacity of the cer- 

the use of pointer ^"^^^^ ^%o U.L. a space 

tiftoate list. The ^^'^''^tlt «nd^he corresponding UBL 

to store a., the f or t^^^ peda.iy requested cer- 

r,st 372 associated UBUor ine p ^ 

tH^ates in .^^^;^':X^Zlca^.. from certain 
sen^ice web ^'^f '^^^fSUb site identified by http: 
CAS. For example, ^'^^''^^^^^^^^^^.^s signed by CA 
//www.finacial.com ^J^^^f "^^^^^^^^^^^^ user can spe- 
S1 . By seH-provisioning the accou . 

. certificate in t^-f/j-^^tp^^^^^ establish a con- 
mobile d--^^^^^/^::,","Sacial.co^^ When the request 
nection to ^^Pj^^' .^gcialxom is received m the 
comprising Mtp.//www^'na ^ ^^^^.^^^ 

proxy sender dev^c^ l^^^^^^^ 

corresponding certificate, rne 1^ 

^^-^^^^-';^X ^^^<^-^^^^'^ 382 acquired by 
finacial.com. Generally, i „ceDtable to many web 

the CMM 342 is a 9«f "^a ^f^^' '"^^'"^ 

Sites and not ^^^ft^"!^^^^^^^ ^ °^ 


""'^rhfrTTse"". £5 '.r.h. CA a. scon a. 
T^t^XTo, .io.e cWicales. Ane. a fee 

""""r^o^ w^o. 'eB,i.a Oisliosulshed 
^ <«slln9ui*e<f name is com- 

" "pS;Sair™.s «"*-rra^."r 
r "r^.ssss^?rn— ^ .... ^ . 

tier and Its corresponoi y ^ ^ _ or Organiza-. 
=XVZ S°;r 'SsHTn'^'heT^^ of the distj. 

directorytreethatisnowbenngu^^^^ ^^p^^ 

pages- for the ''^^^"^tronto iSiTaddresses. The direc- 
ers, services, and etecton^^^^^^^ 

30 tory is Jr^J^J^^^^^^^ countries are subdi- 

tions and countries are at tne v, 

vided into states or ^^^^^^^^^,^^^^^^6 name is 
v^ed in various ways^A e^^^^^^^^^ 

the path from one ^^^^^^^^^ -.^hed name traverses 
35 directory tree. The enti e ° ^ ^^at rep- 

rrtiTprr^^ "^^^^ 

.0 guished- in the ^^^'^'^Jf.lSng,^ name gener- 

Tdt th': 9— Td 

ated by »he dis ing account, the distinguished 

c.atedeventua.^w^^^^^^ 

riame prefix generator 4UDg concatena- 

45 tinguished name. ^^^^ Pjf ^JJ^^^^er ID. for example, 
tion of a timestamp and a sub«:r«er _^ 

-^J^^^Sr^^ - - names m„s, .e 

55 distinguish d. invokes the 

^p:iS;rcTX-i^-W."*es«Wosin,.«. 
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of library functions which generates the private k y 
based on the public key that is generated with supplied 
seed information. To conform to the industry standard, 
the set of library used in the key pair generator 412 is 
supplied by RSA Data Security, Inc. having an address 
of 100 Marine Parkway, Suite 500, Redwood City, CA 
94065. The generated keys are generally in the form of 
a sequence of binary numbers, such as 
1110101100001. ..00101 and unlikely to be duplicated 
without knowing the source to generate them. To gen- 
erate a pair of unique private and public keys, a random 
number, as the source, must be provided according to 
the set of library It is understood to those skilled in the 
art that there are many ways to get the random number. 
One of the commonly used methods is to generate the 
random number through a one-way hash function from 
a noise source that nnay be hard-coded or from network 
traffic Information. The one-way means that it is signifi- 
cantly easier to perform in one direction (the forward di- 
rection) than in the opposite direction (the inverse direc- 
tion), which makes it unlikely to derive the private key 
from the public key One example of such hash functions 
is to multiply a value Itself a certain number of times and 
followed by a modulo operation. 

[0030] The certificate engine 402 creates a new entry 
for the certificate in the certificate database and the cor- 
responding private key from the key pair is stored in the 
new entry, meanwhile the certificate engine 402 uses 
the generated distinguished name and the public key 
obtained from the key pair generator 41 2 to generate a 
certificate signing request or CSR. The CSR is a public 
standard fonnat for requesting certificates from a CA. 
The CSR contains, among other things, the public key 
that is to be certified by the CA and the distinguished 
name associated with the public key The CSR is a bi- 
nary block of data packaged in a certificate request In a 
standard form that is then sent to the CA through the 
HTTP module 330 using HTTP. 

[0031] Upon receiving the certificate request, the CA 
verifies the supplied information therein and attests to 
the validity of the user's public key along with other in- 
fbrmatbn by signing the certificate. The C A then issues 
a certificate response, which may contain the signed 
certificate or an error. If the certificate response contains 
an error, that means the certificate being requested fails, 
a new process must be restarted. When the certificate 
response comes back from the CA. the certificate en- 
gine 402 extracts the distinguished name from the re- 
ceived certificate and updates the corresponding entry 
in the certificate database through the certificate storage 
library 408. At this point that entry contains the signed 
certificate which has the public key embedded iri it and 
the corresponding private key which has been referred 
to as the tree certificate. 

[0032] When the mobile device 302 is activated, a re- 
quest is submitted for creating a certificate for the de- 
vice. The certificate engine 402 fetches a free certificate 
from the certificate database and associates it with the 


devrce ID. The association is perform d by nnaking an 
entry In a separate temporary table called 
device_cert_map_tbl, preferably in a RAM of the proxy 
server 114. 

5 [0033] The certificate storage (CS) library 408, or CS 
library, is used to administrate the certificate database 
and from time to time receives certificate revocations 
lists from CAs. A certificate revocation list (CRL) is a list 
of certificates that have been revoked before their 
10 scheduled expiration date. There are several reasons 
why a certificate might need to be revoked and placed 
on a CRL. For instance, the key specified in the certifi- 
cate might have been compromised, or, the user spec- 
ified in the certificate may no tonger have authority to 
IS use the key. To be more specific, a user name associ- 
ated with a key is "Mr. Smith, Vice President, XYZ Corp. 
■ If Mr. Sniith left the company, the company may not 
want him to be able to sign messages with that key. and 
therefore, the company would place the certificate on a 
CRL. When verifying a signature, one can check the rel- 
evant CRL to make sure the signer's certificate has not 
been revoked. Whether it is worth the time to perform 
this check depends on the importance of the signed doc- 
ument. The CRL is maintained by the CA and provides 
25 information about revoked certificates that were issued 
by the CA. The CRL, however, only lists current valid 
certificates, since expired certificates should not be ac- 
cepted in any case; when a revoked certificate is past 
its original expiration date, it is removed from the CRL. 
30 Although a CRL is maintained In a distributed manner, 
there may be central repositories for a CRL, that is, net- 
work sites containing the latest CRLs from many organ- 
izations. 

[0034] The certificate library 408 receives such CRL 
55 and informs the certificate engine 402 to take action 
when any certificates maintained by the CMM 342 is in 
the list. It is described that the CMM 342 maintains a 
certificate database housing a fixed number of free cer- 
tificates. When the CMM 342 associates a certificate 
40 from the certificate database to a user account, the as- 
sociated certificate must be valid. This is guaranteed by 
first consulting with the CRL through the CS library 408. 
If a fetched certificate from the certificate database is 
somehow on the CRL, the fetched certificate is discard- 
^5 ed and a next certificate Is fetched from the certificate 
database. A check-up of the fetched certificate with the 
CRL is always performed in the CS library 408 before 
the fetched certificate is associated to the account. It Is 
understood to those skilled in the art that the check-up 
so with the CRL may be performed by an exhaustive com- 
parison. The time or computation It takes to do the 
check-up regardless of the length of the CRL is afford- 
able as all are being carried out in the proxy server 114 
asynchronously with the mobile devk:e 416. 
55 [0035] In an example of operations in the CMM, the 
maln() function creates a TCertEngine object and calls 
Initialized by a function named Initialize which creates 
the necessary threads to service HTTP client based re- 
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quests. It also creates threads that monitor certificates 
in the certificate database. When the thread is created 
it monitors available resources and calls GenerateCert 
in TCertHttpProtolo create certificates. This thread us- 
es TDBCertPool to create a new entry In database for 
th certificate pool. 

[0036] The function GenerateCert gets a new Distin- 
guished Name from the Distinguished Name Generator. 
It also gets a new public/private key pair from the Key 
Pair Generator. GenerateCert used this information to 
construct a CSR. It then issues a request to a CA over 
HTTP using SendCSR method in THttpCertRequest. 
When the certificate response comes back from the C A, 
it updates the entry in the free pool using TDBCertPool. 
[0037] When a free certificate needs to be associated 
with a user account, the HandleCreateCert method in 
TCertCreateCallback is invoked. This method extracts 
a new certificate from the free certificate pool using func- 
tions In TDBCertPool. The method then calls functions 
in TDBDeviceMap to make a new entry in the 
device_cert_map_tbl. It then returns a response to the 
caller. The Reissuer thread. TCerlReissueThread, calls 
ReissueCert in TCertHttpProto to have certificates reis- 
sued. It calls methods on TDBCertPool to TDBDeviceM- 
ap to revoke certificates in the free pool and those that 
are associated with the device. 

[0038] Figures 6 A and 6B illustrates an operational 
flowchart of the centralized certificate management sys- 
t m in the present invention and should be understood 
in conjunction with Figures 3 and 4. Complied and linked 
processes of the present invention are loaded into a 
proxy server 502 and cause the proxy server 502 to per- 
form the centralized certificate management. It is under- 
stood to those skilled in the art that a proxy server Is a 
server computer or device, generally equipped with suf- 
ficient computing power and memory, that is loaded with 
applications that cause the device to service other com- 
puting devices, hence the applications therein are com- 
monly referred to as the server and the device itself is 
referred to herein as server device. The computing de- 
vices in the present invention are the thin devices that 
may be mobile devices, cellular phones and the Internet 
appliance controllers. 

[0039] At 504. the CMM 324 cause the server device 
502 to maintain a certificate database that is preferably 
stor d in a local storage driver in the server device 502. 
The certificate database reserves a fixed number of free 
certificates signed by a CA yet to be associated to a user 
account or a thin client. By maintaining the ready-to-use 
free certificates in the database, the thin client can get 
a certificate associated thereto without a noticeable time 
delay, needed computing power and memory. At 506, 
the number of the available free certificates is examined. 
If the number drops, a process to get new certificate 
starts at 510. It should be understood that the number 
of the free certificates in the certificate database is 
dropped sometime because of the certificate updating 
at 506. To ensure that the certificates to be associated 
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with user accounts are always valid, the CS library 408 
constantly updates the free certificates in the certificate 
database according to a certificate updating message 
received from a CA or commonly used repository site. 
s The certificate message may comprise a CRL or Insert/ 
delete query, which causes the CMM 324 to discard 
some of the free certificates, hence the number of the 
free certificates decreases: In any case, the CMM 324 
tries to maintain the level of the free certificates In the 
TO certificate database by getting new certificates from a 
CA. When the process to get a new certificate starts, the 
CMM 324 first gets a distinguished name for the new 
certificate by calling the DN prefix generator 406 and 
DN generator 404 at 51 0 and 51 2 and then calls KP gen- 
is erator 412 to generate a pair of private key and public 
key therefor at 514. A certificate request is formed at 
516 to include a CSR comprising the generated distin- 
guished name and the public key. At 518, the CMM 342 
communicates with the C A using HTTP through the HT- 
20 TP server 330. Upon receiving the certificate request, 
the CA attests to the validity of the public key along with 
other information by signing the certificate and returns 
a certificate response to the CMM 342. thus a signed 
certificate is created at 520. The signed certificate is de- 
25 posited as a free certificate to the certificate database 
at 522. Logically the number of the free certificates is 
incremented by one and compared with the fixed 
number or threshold. If the incremented number Is still 
bebwthe threshold, the process to get a new certificate 
30 is repeated from 510 till the number of the free certificate 
in the certificate database reaches the threshold. 
[0040] Meanwhile the CMM 342 maintains a plurality 
of user accounts at 536, each preferably assigned to 
one thin client. Each of the accounts has one or more 
35 certificates exclusively associated with the account. 
When a thin client is activated to be serviced by the serv- 
er device 502, a new user account is established there- 
for at 538. As described before, the user account may 
comprise a device ID, a subscriber ID, user Info, a cer- 
40 tit icate list and a private key list. The device ID is a piece 
of information that helps the server device 502 to rec- 
ognize which thin client device rt is supposed to service 
and entered when the thin device is activated. The user 
info contains inform regarding the account configuration 
45 and the services that the thin client needs. The subscrib- 
er ID, the certificate list and the private key list are ob- 
tained when a certificate is associated thereto. At 540, 
a request to get a certificate is made. Upon receiving 
the request at 542, the CMM 342 fetches a valid free 
50 certificate from the certificate database and associates 
the free certificate to the account. 
[0041] The ^resent invention Includes a method of 
self provisioning. Specifk^ally, a user may attempt to 
self-provision as illustrated at step 544 in Figure 6B. 
55 First, the attempts to access a user account by logging 
onto the account. If the user is logging in using the thin 
client device that has a devk:e ID. the access is quickly 
authenticate. If the user is logging in using a PC con- 
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necled to the Internet, then the user must enter the cur- 
rent usemame and password. After obtaining access, 
the user may change the username and/or password at 
step 572. The user can then access the account from 
the thin client or another computing device to request a 
certificate from a user-specified CA at 578. 
[0042] After the thin client Is activated by establishing 
the account having one or more certificates in the server 
device 502, it is now possible for the thin client to estab- 
lish secure and authenticated communication session 
with some secure web sites to conduct private commu- 
nication therebetween- At 550, the sen/er device 502 re- 
ceives a session request from the thin client to establish 
a secure and authenticated communication session with 
a web site identified by a URL. The session request 
comprises the device ID of the thin client in order for the 
server device 602 to recognize the thin device and con- 
sequently authorize such request therefrom. At 552, the 
device ID is extracted from the session request and 
compared with the device ID in the user account. If the 
devices IDs are matched, the thin device is authorized 
and further examined per the corresponding account 
thereof. At 544, the certificate in the matched account 
is fetched to be included in the session request that is 
sent to the desired web site using HTTPS. At 558, an 
authentication between the thin client and the contacted 
web site is carried out by examining each other's certif- 
icate. If each certificate is trusted, a session key is re- 
sulted therefrom and used to encrypt information to be 
exchanged between the thin client and the web site, 
hence a secure and authenticated comrhunication is es- 
tablished. 

[0043] The present invention has been described in 
sufficient detail with a certain degree of particularity. It 
is understood to those skilled in the art that the present 
disclosure of embodiments has been made by way of 
example only and that numerous changes in the ar- 
rangement and combination of parts as well as steps 
may be resorted without departing from the spirit and 
scope of the invention as claimed. Accordingly, the 
scope of the present invention is defined by the append- 
ed claims rather than the forgoing description of embod- 
iments. 
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A method for managing centralized certificates in a 
proxy sen/er device for a plurality of thin client de- 
vices coupled to the proxy server through a data 50 
network, the method comprising: 

maintaining a free certificate database acces- 
sible by the proxy sen/er, the free certificate da- 
tabase comprising a plurality of free certificates 
issued by a Certificate Authority(CA) wherein 
each of the free certificates has a correspond- 
ing public key and a corresponding private key; 


55 


maintaining a user account database accessi- 
ble by the proxy s rver, the user account data- 
base comprising a plurality of user accounts, 
each of the thin client devices associated with 
one of the user accounts wherein each of the 
user accounts comprises a device ID. a list of 
public and private keys assigned to the user ac- 
count, and a list of certificates assigned to the 
user account; and 

adding at least one certificate taken out from 
the free certificate database to each user ac- 
count In the user account database. 

The method as recited in claim 1 . wherein the main- 
taining the certificate database in the proxy server 
comprises: 

receiving a certificate request when the number 
of free certificates in the certificate database is 
lower than a low threshold number; and 
generating a new certificate wherein the gener- 
ating the new certificate comprises, 

generating a distinguished name for the 
new certificate; 

generating a new private key and a new 
public key for the hew certificate; 
sending the certificate request to the CA 
wherein the certificate request comprises 
the generated new public key; and 
receiving the new certificate signed by the 
CA; and 

depositing the new certificate in the free.certifr 
icate database. 


The method as recited in claim 1 or 2. wherein the 
maintaining the user account database comprises: 

retrieving one of the free certificates from the 
free certificate database when a new thin client 
device is activated; 

establishing a new user account related to a 
new device ID apd a new subscriber ID; and 
associating the retrieved free certificate and the 
corresponding private key and public key with 
the new user account; 

The method as recited in any preceded claim further 
comprising: 

updating a user account in the user account da- 
tabase associated with a valid device ID upon 
receiving a newly provisioned username and 
password from a thin client device having the 
valid devic ID. 
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5. The methcxJ as recited in claim 4 wherein the user 
account in the user account database is accessible 
with the newly provisioned username and password 
from a computer coupled to the proxy server 
through the Internet. 

6. An apparatus for managing centralized certificates 
in a proxy sen/er device for a plurality of thin client 
devices over a data network, the apparatus com- 
prising: 

a certificate manager module for generating 
free certificates; 

a free certificate database coupled to the cer- 
tificate manager module for storing the free cer- 
tificates from the certificate manager module 
until reaching an upper threshold; 
a user account database, the user account da- 
tabase accessible by the proxy server device, 
the user account database comprising a plural- 
ity of user accounts, each of the thin client de- 
vices associated with one of the user accounts 
wherein each of the user accounts comprises 
a device ID and a list of certificates assigned to 
the user account; and 

a certificate assigning module for associating 
one of the free certificates in the free certificate 
database to a new user account in the user ac- 
count database associated with a newly acti- 
vated thin client device. 

7. The apparatus as recited in claim 6; wherein the. 
certificate manager module comprises: 

a certificate engine communicating with the 
certificate assigning module; 
a name generator generating a unique name 
lor a new certificate; 

a key pair generator generating a private key 
and a public key for the new certificate; and 
a certificate request module for contacting a 
certificate authority for the new certificate, 
wherein the certificate request comprises the 
public key and the unique narhe. 

8. The apparatus as recited in claim 7, wherein the 
name generator comprises, a distinguished name 
generator that combines a timestamp along with a 
subscriber ID. 

9. The apparatus as recited in claim 8; wherein the 
certificate manager module updates the free certif- 
icate database upon receiving certificate update re- 
quest. 

10. The apparatus as recited in claim 9, wherein the 
certificate update request comprises a certificate 
revocation list. 


11. The apparatus as recited in claim 10, wherein the 
certificate update request further comprises an In- 
sert/delete query. 
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Client verifies the server's 
digital ID. If requested, 
the client sends its digital 
ID in response to the 
server's request 


When authentication is 
complete, the client sends 
the sen/er a session key 
encrypted using the 
server's public key 


Server responds, sending the 
client its digital ID, the server may 
also request the client's digital 
ID for client authentication 



If client digital ID is authenticated, 
server accepts the request, 
otherwise server denies the 
request. 



Once a session key is established, 
secure communications commence 
between the client and the server 
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